Typically, a telecommunication network is shared by many users. The resources of the network (e.g., cell number/size, transmission bandwidth and routing/switching capacity) are engineered to handle a given demand with a given quality of service. The demand is typically based on an “average user,” the behaviour of which is constructed from a mix of assumptions and measurements. Many tariffs (e.g., flat rates) are set to match the resources consumed by the average user.
The statistical methods used for dimensioning networks and setting tariffs work well as long as user behaviour is relatively homogeneous. If this is not the case, then the result may be congested networks with poor performance and unbalanced tariffs where less active users in effect subsidise more active users.
Several measurements have shown that the degree of activity varies considerably between different users. In more detail, the vast majority of users exhibit low or medium activity, while a small number of users exhibit high or extreme activity. The users exhibiting high or extreme activity (a.k.a., “heavy hitters”) pose a potential problem to network operators because such users tend to offset the dimensioning model by flooding the network and creating traffic peaks at the expense of the other uses. In addition to the notion of “heavy hitters,” there is the notion of “bad applications,” which (at present) typically include file sharing applications that use peer-to-peer protocols. The term “heavy hitter” is often used in this context as well.
The root of the problem presented by “heavy hitters” is the flat rate tariff scheme. An obvious solution is thus to charge each user by the amount of network traffic the user generates, in the same way as telephone use is charged by time. The problem with this solution, however, is that traffic volumes are hard to understand for ordinary users. Hence, the result is an uncertainty about costs which results in ordinary users tending to refrain from using the service at all.
Another option is to impose some sort of upper limit on traffic volume. For example, a user may be allotted a “bucket” of bytes (or any other suitable unit of network data, e.g., a bucket of packets) on a monthly basis. Each user's bucket may be decremented for every unit of data (e.g., byte) transmitted or received. The user reaches the upper limit when the user's bucket becomes empty. The upper limit (i.e. the size of the users bucket) can easily be chosen such that most ordinary users never will hit this upper limit. Heavy hitters may be charged a higher monthly rate in exchange for a larger bucket.
Although buckets are simple and work well in terms of metering, they only indirectly address the problem of congestion. Congestion comes and goes both regularly according to the time of the day and irregularly in a random fashion, while a bucket mechanism counts all bytes in the same way.
This phenomenon is well known in voice networks where operators (partly) solve the problem by applying different tariffs at different times of the day. This solution can be applied to data networks, for example, by decrementing buckets at different rates at different times of the day.
A remaining shortcoming of this solution is that time of day only provides an approximate estimate of congestion rather than a measure of actual congestion. Moreover, users may adapt their habits to any time based scheme, and the changing user behaviors may require continual adjustments to the decrement rates, e.g., changing the time at which a lower “night tariff” is in effect. The continual adjustments required by this solution may work against one of the desired advantages of the flat rate tariff scheme: perceived simplicity.
Additionally, network operators may attempt to mitigate the effects of network congestion using “traffic shaping”, that is, intentionally delaying the transmission of some data so that network resources remain or become available for other purposes. For example, a network may assign priority levels to data packets based upon specified criteria, such as the type of application that generated the data or the user associated with the data. The network may assign higher priority to data generated by latency-sensitive applications (e.g., voice over Internet protocol (“VOIP”), interactive games, video conferencing, etc.), and may assign lower priority to data generated by applications that are not significantly affected by latency (e.g., email). The network may also assign higher priority to data generated by or intended for preferred users (e.g., emergency services).
During periods of network congestion, traffic shaping may be used to delay the transmission of low-priority data so that network resources remain or become available for the transmission of higher-priority data. On the other hand, during periods without significant network congestion, it would be preferable to transmit all data without introducing any delays. One shortcoming of current traffic shaping systems is that congestion information is generally acquired indirectly (or not at all). This results in a considerable delay (e.g., 5 to 60 minutes) between a change in congestion conditions and a network operator being notified of the change For example, there may be a delay between the time at which congestion begins and the time at which traffic shaping begins appropriately delaying packets, or there may be a delay between the time at which congestion ends and the time at which traffic shaping stops unnecessarily delaying packets. Furthermore, the methods of indirectly acquiring the congestion information tend to be undesirably complex for a network operator to implement. Document US 2006/176810 (Kekki Sami) (D1) discloses a system and method for providing network congestion notification. Document US 2006/250962 (Chikamatsu Yuichiro) (D2) discloses an “edge switch” that is configured such that the switch will “avoid network congestion by limiting the amount of packets to be transferred onto the network when congestion occurs in the network.”